Skip to content

makes the core consumable as a CMake subproject - #37

Open
astronomerdave wants to merge 1 commit into
mainfrom
DH/core-consumable
Open

astronomerdave wants to merge 1 commit into
mainfrom
DH/core-consumable

Conversation

@astronomerdave

@astronomerdave astronomerdave commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor

required to meet camera 2.0 design

From requirements **,

The shared core library contains no registration of its own, so composing it as a dependency never forces a choice, and the final target alone determines which registration is linked.

PR #33 satisfied the registration half. This PR makes the other half true by making the composition work.

** in this case, "requirements" means specifically from my SPIE paper, section 4, but this is being written into the detailed design description document.

This splits camerad_base from controller target, gives it its own
include and link interface, stops the source-tree output paths and
the g++ selection from running when not the top-level project.
@prkrtg

prkrtg commented Sep 24, 2026

Copy link
Copy Markdown
Contributor

It looks like you can't reach camerad_base without -DCONTROLLER. There is an error in
the controller selection which occurs during add_subdirectory, before the base library is
declared, so composing the core still forces a choice. And a consumer that does pass it
gets all the pieces such as camerad, emulator, listener, socksend, the install
rules, etc.

Possible fix is moving the camerad_base block above option(CONTROLLER ...) and return() right after it unless a CAMERAD_BUILD_DAEMON flag is set

@astronomerdave

Copy link
Copy Markdown
Contributor Author

It looks like you can't reach camerad_base without -DCONTROLLER.

Correct, and requiring CONTROLLER is intentional. A build makes two choices, the controller and the interface (which class Interface::create() returns). An instrument has already made the first choice in its own code since its class derives from ArchonInterface, so stating CONTROLLER only states something it already depends on.

There is an error in the controller selection which occurs during add_subdirectory, before the base library is declared, so composing the core still forces a choice.

Right, the error is the missing CONTROLLER above, not a forced choice. "Never forces a choice" is about the interface. If *_interface_factory.cpp were compiled into a library, every project linking that library would get its create(), which would clash with it's own. Keeping it ouf of the libraries restricts create() to only the final camerad target (or the Python module).

And a consumer that does pass it gets all the pieces such as camerad, emulator, listener, socksend, the install rules, etc.

Right, and deliberately left for the next PR. This PR is the first and necessary step towards instruments pulling in the core, rather than the core pulling in every instrument as a submodule. Right now every instrument gets a copy of every other instrument.

It makes the core consumable. I'm doing this piecemeal so that the next PR will decide which targets the core builds when it's consumed.

Possible fix is moving the camerad_base block above option(CONTROLLER ...) and return() right after it unless a CAMERAD_BUILD_DAEMON flag is set

A return() right after the base would also skip the controller library, which a consumer needs, so the fix will look a bit different. I'm also working on that for the next PR.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants